• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention proposes a control method in an on-board subscriber identity module (eUICC1) cooperating with a terminal (T), comprising: receiving identifiers (ID) of services associated with a communication profile (P), execute when the profile is in the active state; determining whether each service (S) is supported by an operating system (OS1) of the on-board subscriber identity module (eUICC1); if not, send an OS update request (OS1); installing said update allowing the operating system to implement the communication profile (P); and sending a request to receive or continue receiving the communication profile (P) to be installed in said embedded subscriber identity module (eUICC1). The invention also relates to a control method implemented by a profile providing server for providing the embedded subscriber identity module (eUICC1) the service identifiers.
    公开号:FR3059194A1
    申请号:FR1661289
    申请日:2016-11-21
    公开日:2018-05-25
    发明作者:Jerome DUMOULIN；Alexis MICHEL
    申请人:Oberthur Technologies SA；
    IPC主号:
    专利说明:

    © Publication no .: 3,059,194 (to be used only for reproduction orders)
    ©) National registration number: 16 61289 ® FRENCH REPUBLIC
    NATIONAL INSTITUTE OF INDUSTRIAL PROPERTY
    COURBEVOIE © Int Cl 8 : H 04 W 8/20 (2017.01), H 04 W 12/06, H 04 L 9/32
    A1 PATENT APPLICATION
    ©) Date of filing: 21.11.16. © Applicant (s): OBERTHUR TECHNOLOGIES ©) Priority: Public limited company - FR. @ Inventor (s): DUMOULIN JEROME and MICHEL —X ALEXIS. (43) Date of public availability of the request: 25.05.18 Bulletin 18/21. ©) List of documents cited in the report preliminary research: Refer to end of present booklet (© References to other national documents ® Holder (s): OBERTHUR TECHNOLOGIES Company related: anonymous. ©) Extension request (s): ® Agent (s): CABINET BEAU DE LOMENIE.
    INSTALLING A PROFILE IN AN ON-BOARD SUBSCRIBER IDENTITY MODULE.
    FR 3 059 194 - A1
    The invention provides a control method in an on-board subscriber identity module (eUICC1) cooperating with a terminal (T), comprising: reception of identifiers (ID) of services associated with a communication profile (P), execute when the profile is in the active state; determination of whether each service (S) is supported by an operating system (OS1) of the on-board subscriber identity module (eUICC1); if not, sending a request to update the operating system (OS1); installation of said update allowing the operating system to implement the communication profile (P); and sending a request to receive or continue receiving the communication profile (P) to be installed in said on-board subscriber identity module (eUICC1). The invention also relates to a control method implemented by a profile supply server for supplying the on-board subscriber identity module (eUICC1) with the service identifiers.
    i
    Invention background
    The present invention relates to the field of embedded subscriber identity modules also called eUICC modules (for "embedded Universal Integrated Circuit Chip"), and relates more particularly to such eUICC modules capable of managing communication profiles.
    In known manner, a conventional SIM card is configured to allow a communication terminal (such as a mobile telephone for example), with which it cooperates, to use the communication network of a single telephone operator. To do this, the SIM card includes subscription data such as an IMSI identifier (for “International Mobile Subscriber Identity”), cryptographic keys and algorithms specific to the associated operator. This subscription data is permanently stored in a read only memory.
    When a mobile phone attempts to use the services of a cellular network, it sends all the subscription data, stored in the SIM card, necessary for the network operator to obtain access to the required services. The operator can thus authenticate the user and check using an HLR database (for “Home Location Register”) that he has subscribed to the requested service. If so, the operator then authorizes access to the mobile telephone carrying the SIM card, the data of which has been used for authentication and registration with the operator's network.
    Furthermore, reprogrammable SIM cards are known today, and more particularly on-board subscriber identity modules, also called eUICC modules. These reprogrammable modules allow a user to change operator without having to physically replace the SIM card in the mobile phone. The main specifications of an eUICC module are defined by the GSMA group (for “Global System for Mobile Communications Association”) in the GSMA standard SGP.02 v3.1 entitled “Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 3.1” dating from May 27, 2016. An eUICC module is a secure, generally small, hardware element that can be integrated into a communication terminal (in a mobile terminal for example) in order to implement the functions of a traditional SIM card.
    In particular, an eUICC module is capable of containing one or more communication profiles (hereinafter also called "profiles"). Each profile is contained in a dedicated secure domain called ISD-P in accordance with the GSMA standard. When a communication profile is active, it allows the communication terminal in which it is embedded to securely access the communication network of an associated operator, as well as the services defined by the profile in question. By changing the active communication profile in the eUICC module, it is possible to change the operator or modify the access to associated services (voice and / or data services for example).
    It is now possible for an eUICC module, embedded in a communication terminal, to receive a new communication profile remotely. The provision of such a profile is generally initiated by the operator of the communication network associated with the profile, for example by means of an SM-SR server in charge of the remote management of the profiles in the eUICC module.
    Once received, the eUICC module installs the profile in order to allow the terminal to communicate with the communication network associated with the profile when the latter is in the active state in said terminal.
    The SIMALLIANCE standard entitled "eUICC Profile Package: Interoperable Format Technical Specification" (version 2.0) dated April 18, 2016 (hereinafter simply called "SIMALLIANCE") specifies in particular the structure of a communication profile during a phase of loading in a terminal and the way in which an eUICC module remotely retrieves such a profile and proceeds to its installation.
    The SIMALLIANCE standard provides in particular that a profile is sent to an eUICC module in the form of a plurality of profile elements (known as “Profile Elements” or PE in English). These profile elements are defined in a descriptive language (named ASN.l) that can be interpreted by the eUICC module, this language being defined jointly by the international standardization organization, the international electrotechnical commission and the international telecommunications union.
    The first profile element sent to the eUICC module during the remote download is generally a profile header (called PEH for “Profile Element Header” in English). In accordance with the SIMALLIANCE standard, this profile header contains a certain amount of information concerning the corresponding profile, in particular a list of profile services to be supported by the recipient eUICC module.
    Still according to the SIMALLIANCE standard, each service in the profile is specified in the list of services in the header as being compulsory or optional depending on the level of importance of the service considered. If a profile service is specified as mandatory in the header, it is imperative that the eUICC module receiving the profile supports the service in question, otherwise the profile is refused by the eUICC module and the installation process is abandoned.
    Consequently, a problem exists today in that an installation of a profile in an eUICC module is liable to fail if said eUICC module is not capable of implementing certain services, in particular services specified as mandatory. in the header of said profile. Failure to install a profile is undesirable insofar as resources have been requested in vain and the fact that neither the operator nor the terminal user can benefit from a new profile when the latter requires the implementation of a service not supported by the eUICC module. This results in a lack of flexibility and a risk of premature obsolescence for the eUICC modules.
    No satisfactory solution today makes it possible to overcome the problems mentioned above and, more generally, to efficiently manage the installation of a communication profile in an on-board subscriber identity module (or eUICC module).
    Subject and summary of the invention / Summary
    To this end, the present invention relates to a first control method implemented by an on-board subscriber identity module (or eUICC module) capable of cooperating with a communication terminal, said electronic module comprising:
    - reception of at least one identifier of a respective service, of a communication profile, to be implemented when said communication profile is installed and in the active state in the onboard subscriber identity module;
    - determination of whether each service is supported by an operating system of the on-board subscriber identity module;
    - if not, sending a request to update the operating system;
    - If an update of the operating system is received in response to said sending, installation of said update allowing the operating system to at least partially implement said communication profile; and
    - after completion of said installation, sending a request to receive or continue receiving the communication profile, including said at least one service (S), to be installed in said on-board subscriber identity module.
    When an eUICC module detects that its operating system does not support at least one service specified in a profile to be installed, the invention advantageously allows said eUICC module to obtain the necessary update so as to compensate, at least in part, its inability to implement said at least one unsupported service. Once the update has been carried out, the eUICC module can install the profile so as to offer, when the profile in question is in the active state, access to one or more services associated with said profile.
    According to a particular embodiment, the method comprises, in response to said request to receive or continue said reception, a reception of all or part of the communication profile so as to allow the installation of the profile in the subscriber identity module on board.
    According to a particular embodiment, the method comprises the installation of the communication profile in the on-board subscriber identity module once said profile has been obtained in its entirety.
    According to a particular embodiment, said communication profile authorizes, when installed and in the active state in the on-board subscriber identity module, the communication terminal to communicate with a communication network associated with said communication profile .
    According to a particular embodiment, the method comprises a comparison of the capacities of the operating system with each service (S) associated with said at least one identifier;
    the determination of whether at least one said service is not supported by the operating system being carried out on the basis of the result of said comparison.
    According to a particular embodiment, the reception of said at least one identifier comprises the reception of a first portion of the communication profile, said first portion comprising said at least one identifier.
    According to a particular embodiment, the first portion is a header portion of the communication profile.
    According to a particular embodiment, the method comprises, after completion of said installation of the update, the sending of said request to continue receiving the communication profile in order to receive at least a second portion of the communication profile supplementing said first portion so as to obtain the entire communication profile to be installed in the on-board subscriber identity module.
    According to a particular embodiment, said at least one identifier is received from a profile supply server, the method comprising, if at least one said service is not supported by the operating system, sending a request to put on hold the profile supply server in order to delay the reception of at least part of the communication profile.
    According to a particular embodiment, upon receipt of said at least one identifier, the method comprises:
    - reception, in association with each service identifier, of a degree of importance of said service, said degree of importance indicating whether the corresponding service must be supported by the operating system when the communication profile is installed in the embedded subscriber identity module.
    According to a particular embodiment, the on-board subscriber identity module sends said request to receive or continue receiving the communication profile only if the operating system, once updated, supports at least each service of the communication profile indicated by the associated degree of importance as having to be necessarily supported by the operating system.
    According to a particular embodiment, if the operating system, once updated, does not support at least one service of the communication profile indicated by the degree of importance associated as not necessarily having to be supported by the system of operation, the on-board subscriber identity module:
    - proceeds to send said request to receive or continue receiving the communication profile; and
    - carries out a marking of the communication profile, once said profile is installed in the on-board subscriber identity module, so as to indicate that at least one service of the communication profile, which does not have to be necessarily supported by said system of operating, is not supported by said operating system.
    According to a particular embodiment, the marking comprises a modification, in the communication profile installed in the on-board subscriber identity module, of a parameter to indicate that the on-board subscriber identity module is configured to implement in a restricted manner said at least one service of the communication profile.
    According to a particular embodiment, if the operating system, once updated, does not support at least one service of the communication profile indicated by the degree of importance associated as not necessarily having to be supported by the system of operation, the process includes:
    - sending of a notification indicating that the on-board subscriber identity module is configured to implement said at least one service of the communication profile in a restricted manner.
    According to a particular embodiment, during said reception, said at least one identifier and each associated degree of importance is received in a header of said communication profile, said header further comprising a parameter, in which, after completion of said installation , the on-board subscriber identity module sends said request to continue receiving the communication profile only if the parameter is in a predefined state.
    In a particular embodiment, the different steps of the first control method as defined above are determined by instructions from computer programs.
    Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in an on-board subscriber identity module, or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of the first control process as defined above.
    The invention also relates to a recording medium (or information medium) readable by a computer, and comprising instructions of a computer program as mentioned above.
    Correlatively, the invention relates to a second control method implemented by a profile supply server to supply a communication profile to an on-board subscriber identity module cooperating with a communication terminal, comprising:
    - sending, to said on-board subscriber identity module, at least one identifier of a respective service, of a communication profile, to be implemented when said communication profile is installed and in the active state in the embedded subscriber identity module;
    - putting on hold the sending of at least part of the communication profile to the on-board subscriber identity module;
    - after updating said operating system by the on-board subscriber identity module, receipt of a request to send or continue sending the communication profile, including said at least one service; and
    - in response to said request to send or continue sending the communication profile, sending all or part of the communication profile in order to allow the installation of said profile in the on-board subscriber identity module.
    In a particular embodiment, the different steps of the second control method as defined above are determined by instructions from computer programs.
    Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a server, or more generally in a computer, this program comprising instructions adapted to the implementation implementing the steps of the second control method as defined above.
    The invention also relates to a recording medium (or information medium) readable by a computer, and comprising instructions of a computer program as mentioned above.
    Note that the programs mentioned in this presentation can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form. , or in any other desirable form.
    In addition, the above-mentioned recording media can be any entity or device capable of storing the program. For example, the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disc. hard.
    On the other hand, the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from a network of the Internet type.
    Alternatively, the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.
    The invention also relates to an on-board subscriber identity module configured to implement the first control method as defined above. More specifically, the invention relates to an on-board subscriber identity module (or eUICC module) capable of cooperating with a communication terminal, said on-board subscriber identity module comprising:
    a reception module configured to receive at least one identifier of a respective service, of a communication profile, to be implemented when said communication profile is installed and in the active state in the subscriber identity module embedded;
    - a determination module configured to determine whether each service is supported by an operating system of the on-board subscriber identity module;
    an update module configured, if each service is not supported by said operating system, to send a request for updating the operating system, said update module being configured, if an update operating system update is received in response to said update request, to install said update allowing the operating system to at least partially implement said communication profile; and
    a sending module configured, after completion of said updating installation, to send a request to receive or continue receiving the communication profile, including said at least one service, to be installed in said subscriber identity module on board.
    It will be noted that the various embodiments mentioned above in relation to the first control method of the invention as well as the associated advantages apply analogously to the on-board subscriber identity module of the invention.
    The invention also relates to a profile supply server configured to implement the second control method as defined above. More specifically, the invention relates to a profile supply server for supplying a communication profile to an on-board subscriber identity module cooperating with a communication terminal, comprising:
    a sending module, said on-board subscriber identity module, of at least one identifier of a respective service, of a communication profile, to be implemented when said communication profile is installed and active state in the on-board subscriber identity module;
    the sending module being configured to put on hold the sending of at least part of the communication profile to the onboard subscriber identity module;
    a reception module configured, after updating said operating system by the on-board subscriber identity module, to receive a request to send or continue sending the communication profile, including said at least one service ; and
    a sending module configured, in response to said request to send or to continue sending the communication profile, to send all or part of the communication profile in order to allow the installation of said profile in the identity module onboard subscriber.
    According to one embodiment, the invention is implemented by means of software and / or hardware components. In this perspective, the term "module" can correspond in this document as well to a software component, as to a hardware component or to a set of hardware and software components.
    Brief description of the drawings
    Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate exemplary embodiments thereof without any limiting character. In the figures:
    - Figure 1 schematically shows an eUICC module cooperating with a profile supply server and an update server via a terminal, according to a particular embodiment of the invention;
    - Figure 2 shows schematically a list of capacities of an eUICC module of fig 1, according to a particular embodiment of the invention;
    - Figure 3 shows schematically an eUICC module, according to a particular embodiment of the invention;
    - Figure 4 schematically shows a profile supply server, according to a particular embodiment of the invention;
    - Figure 5 schematically shows the structure of a communication profile to be installed in an eUICC module, according to a particular embodiment of the invention;
    - Figure 6 shows, in the form of a diagram, the steps of a control method implemented by an eUICC module and by a profile supply server, according to a particular embodiment of the invention;
    - Figure 7 schematically shows a list of service identifiers, according to a particular embodiment of the invention;
    - Figure 8 shows, in the form of a diagram, the steps of a control method implemented by an eUICC module and by a profile supply server, according to a particular embodiment of the invention;
    - Figure 9 schematically shows a list of service identifiers, according to a particular embodiment of the invention;
    - Figure 10 shows, in the form of a diagram, the steps of a control method implemented by an eUICC module and by a profile supply server, according to a particular embodiment of the invention;
    - Figure 11 schematically shows a list of service identifiers, according to a particular embodiment of the invention; and
    FIG. 12 represents, in the form of a diagram, the steps of a control method implemented by an eUICC module and by a profile supply server, according to a particular embodiment of the invention.
    Detailed description of several embodiments
    The invention proposes to prepare the installation of a communication profile in an eUICC module by offering the possibility for the latter to update its operating system when one or more services provided by the profile to be installed are not supported by the operating system of the eUICC module concerned. The invention further aims to install the profile in question once the operating system of the recipient eUICC module has been updated.
    The invention relates in particular to a method implemented by an eUICC module (and to the eUICC module in question) to allow such an update when a profile must be installed in the eUICC module. The invention also relates to a method implemented by a remote server (and on the server itself) cooperating with the eUICC module to prepare the installation of a profile in the eUICC module.
    In the present description, by “active” profile or profile in “active” state, it is understood that a communication profile is activated in an eUICC module in order to authorize the communication terminal (with which the module eUICC cooperates) to communicate with the communication network associated with the profile in question. In accordance with the GSMA SGP.02 v3.1 standard cited above (hereinafter referred to as the “GSMA” standard), a profile (or the ISD-P secure domain in which it is contained) is said to be “active” (ENABLE) when its parameter state, called "life cycle", is set to state '3F'. According to this same GSMA standard, a profile is on the contrary said to be "inactive" (DISABLE) when its "life cycle" state parameter is set to the ΊF 'state.
    In this presentation, “service” means any service (or functionality) specified in a communication profile and capable of being implemented by an eUICC module when the profile is installed and in the active state in the eUICC module, provided that this service is supported by the operating system of the eUICC module concerned.
    By way of example, the following services may be cited which may be implemented by an eUICC module, in accordance with the SIMALLIANCE standard:
    - contactless service (allows contactless operations);
    - USIM application as defined by 3GPP;
    - ISIM application as defined by 3GPP;
    - AKA authentication algorithm;
    - TUAK128: TUAK AKA authentication algorithm with a key length of 128 bits;
    - UICC EAP client;
    - Javacard;
    - Multiple USIM, allowing the support of several USIM at the same time;
    - Etc.
    In this presentation, the concept of "operating system" is understood in the broad sense and includes any software module, software block, or computer program executable by the eUICC module to manage and implement one or more profiles of communication.
    Unless otherwise indicated, the elements common or analogous to several figures bear the same reference signs and have identical or analogous characteristics, so that these common elements are generally not described again for the sake of simplicity.
    FIG. 1 diagrammatically represents the structure of an eUICC module (denoted here eUICCl) configured to cooperate with a communication terminal T to allow access to a communication network R. The eUICCl module is for example welded or integrated into the terminal T .
    In the example considered here, the communication network R is a mobile telephone network and the terminal T is a mobile communication terminal, such as a mobile telephone for example. Other examples of communication networks R and of communication terminals T are however possible within the framework of the invention.
    In the embodiment described here, the mobile terminal T can use the eUICCl module to securely access the network R as well as the services provided by the respective telephony operator MNO (for "Mobile Network Operator").
    In this particular embodiment, the mobile terminal T includes an operating system OS2 capable of controlling in particular an INT radio interface. The radio interface INT of the terminal T is configured to transmit and receive radio communications with the outside via, for example, an antenna (not shown). This INT radio interface comprises, for example, in known manner, a radio transmitter / receiver unit coupled to an antenna (not shown). It is also possible to envisage the presence in the terminal T of a plurality of radio interfaces.
    In the embodiment described here, the eUICCl module comprises an operating system OS1 (stored in a non-volatile memory, a read-only memory or Flash for example) coupled to a rewritable non-volatile memory MR.
    The operating system OS1 constitutes an example of a computer program within the meaning of the invention, this program comprising instructions for the execution of the steps of a control method according to a particular embodiment of the invention. The memory in which the operating system OS1 is thus constitutes an example of a recording medium within the meaning of the invention, readable by a processor (not shown) of the eUICCl module.
    As shown in FIG. 1, the non-volatile memory MR of the eUICCl module also includes a privileged security domain ISD-R and two secondary security domains ISD-P, denoted here ISD-P1 and ISD-P2. Each ISD-P security domain (or secure domain) constitutes a secure compartment of the eUICCl module. It will be understood that the particular embodiment envisaged here constitutes only a nonlimiting example of implementation of the invention, the number of ISD-P domains being able in particular to be adapted according to the use case.
    The security domain ISD-R is privileged in that it is notably able to create, delete, activate or deactivate secondary security domains ISD-P in the non-volatile memory MR.
    Each secondary security domain ISD-P is capable of containing a single communication profile P (or operational profile) associated with a particular MNO operator for telephony. Each P profile is thus contained in a dedicated ISD-P security domain. In a known manner, a communication profile P comprises subscription data (eg identifiers (IMSI etc.), cryptographic keys, algorithms (eg authentication), etc.) and may also include a file system, applications, and / or predetermined execution rules. In the example envisaged here, the profiles P conform to the GSMA standard mentioned above.
    In the example illustrated in FIG. 1, it is assumed that the memory MR of the eUICCl module comprises two secondary security domains ISD-P1, ISD-P2, each secondary security domain being capable of containing a unique profile P1, respective P2 possibly each be active or inactive.
    Each of the profiles P1, P2 is configured to authorize, when it is active, the terminal T to communicate in a secure manner with a mobile network R of a communication operator MNO associated with said profile. For the sake of simplicity, it will be assumed in this example that each of the profiles P1, P2 is associated with the same communication network R associated with a single operator MNO, as shown in FIG. 1.
    Each profile P1, P2 further specifies at least one service S which can be implemented by the module eUICCl when the profile considered is in the active state, provided that the operating system OS1 of the module eUICCl supports the service in question. Each profile includes, for example, subscription data required by the operator MNO of the communication network R to obtain access to the required services. This subscription data thus allows the operator to verify (using for example an HLR database) that the user has indeed subscribed to the requested service.
    The operating system OS1 of the eUICCl module is configured to support at least one service. Examples of services likely to be supported by the OS1 operating system are defined in the SIMALLIANCE standard (for example the "contactless" service, USIM, ISIM, SIM, "Milenage", "Cave", EAP, GBA, "Javacard" ...), other types of service are however possible. The ability of the OS1 operating system to implement a service specified in a profile may vary from case to case. In the example shown in FIG. 1, the memory MR of the module eUICCl contains a list TB of the capacities of the operating system OS1 to implement profile services. From this TB list, the eUICCl module is able to determine whether or not it supports a given service.
    FIG. 2 schematically represents the content of the list TB according to a particular example. In this example, the list TB defines four distinct capacities CAP1 - CAP4, collectively noted CAP. It will be noted that a capacity CAP characterizes the ability of the operating system OS1 to implement a single service or several distinct services as the case may be.
    In the example shown in FIG. 1, the eUICCl module is moreover capable of communicating, via the terminal T (and in particular its radio interface INT), in a secure manner with a server SV1 for providing a profile which, in this example, is an SM-SR server (for "Subscription Manager-Secure Routing"). In this example, the server SV1 belongs to the communication network R associated with the profiles PI, P2.
    The communication between the eUICCl module and the terminal T is for example carried out via a link L conforming to standard ISO 7816 (more particularly according to ISO 7816-3 and ISO 78164).
    In the example considered here, the SM-SR server implements an OS3 operating system recorded in an information medium (not shown).
    The eUICCl module is configured to receive, from the remote server SV1, a new profile P and to install it in a secondary security domain ISD-P. The sending of a new P profile to the eUICCl module is, for example, controlled by the operator MNO (for example via the SM-DP server as shown in Figure 1). Once the new P profile has been received and installed in the eUICCl module, the ISD-R privileged security domain can configure the new P profile in the active or inactive state as appropriate.
    As explained in more detail below, the eUICCl module is also configured to receive, before downloading the profile P, a list LT1 of at least one identifier ID of a respective service S specified in the profile P to be installed. This list LT1 allows the eUICCl module to determine which service (s) S must be supported by its operating system OS1 to implement the profile P once the latter is installed and in the active state in the module eUICCl .
    Furthermore, the eUICCl module is configured to cooperate with a remote server SV2 to recover, if necessary, an UPD update of the operating system OS1 of said eUICCl module. It is assumed here that the server SV2 is an update server implementing an OS4 operating system recorded in an information medium (not shown).
    The eUICCl module, the terminal T, the profile supply server SV1 and the update server SV2 together form a system SY.
    It should be noted that certain elements generally present in an eUICC module, in a communication terminal T or even in a communication network R of an operator MNO have been deliberately omitted because they are not necessary for understanding the present invention. In addition, those skilled in the art will understand that certain elements are described here to facilitate understanding of the invention although they are not mandatory or directly involved in implementing the invention. The structure of the system SY represented in FIG. 1 constitutes only one nonlimiting example of implementation of the invention.
    As shown in FIG. 3, the operating system OS1 of the eUICCl module implements, in a particular embodiment, a number of modules defined as follows: a reception module MD2, a determination module MD4, a module for MD6 update, MD8 sending module, MD10 profile installation module. According to a particular example, the operating system OS1 also implements an MD12 marking module.
    The reception module MD2 is configured to receive at least one identifier ID of a service S, of a communication profile P, to be implemented when said profile P is installed and in the active state in the module eUICCl. In the example considered in FIG. 1, the service ID or identifiers are received by the reception module MD2 in the form of a list LT1, transmitted by the server SV1 via the terminal T. The reception module MD2 receives by example said at least one identifier ID in a header (or header portion) of the profile P, as explained in more detail later, other embodiments being however possible.
    The determination module MD4 is configured to determine whether each service S, specified by the identifier (s) ID received by the reception module MD2, is supported by the operating system OS1 of the module eUICCl. To do this, the eUICCl module compares for example the identifiers ID received by the reception module MD2 with the capacities CAP defined in the list TB recorded in the memory MR, and determines, from the result of this comparison, whether each service S specified by the identifier (s) ID received is supported by the OS1 operating system.
    The update module MD6 is configured, in the case where the determination module MD4 detects that at least one service S is not supported by the operating system OS1, to send, to the update server SV2, a request to update the operating system OS1.
    The update module MD6 is further configured, if a UPD update of the operating system OS1 is received in response to said update request, to install the update so as to allow the system to OS1 operation to implement (totally, or at least partially) the communication profile P.
    The sending module MD8 is configured, after completion of the installation of the UPD update by the update module MD6, to send a request to receive or continue (in the particular case where part of the profile has already received by the eUICCl module) the reception of the P communication profile, including (or specifying) said at least one service S, to be installed in the eUICCl module. In the example shown in FIG. 1, this request is sent by the sending module MD8 to the server SV1.
    The MD10 profile installation module is configured, in response to the request mentioned above, to receive or continue reception of all or part of the communication profile P so as to allow the installation of said profile P in the eUICCl module. . Once the entire P profile has been recovered, the MD10 installation module is configured to install the P profile in the eUICCl module.
    The MD12 marking module allows, if necessary, to mark a communication profile P installed in the eUICC module in order to indicate that the OSI operating system does not support at least one service of the communication profile, each service not supported being optional in the sense that it is not compulsory that the OSI operating system supports it for the profile to be implemented in the eUICCl module. If such an optional service is marked, the corresponding P profile is only partially supported by the eUICCl module but can however be implemented within the limit of the profile services supported by the eUICCl module.
    It will be understood that the above definition of modules M2 to M12 constitutes only a non-limiting embodiment of the invention and that embodiments, not including at least one of these modules, are possible in the scope of the invention. At least two of these modules can form a single module implemented in the eUICCl module.
    As shown in FIG. 4, the operating system OS3 of the profile supply server SV1 implements, in a particular embodiment, a certain number of modules defined as follows: a sending module MD20, a receiving module MD22 and an MD24 determination module.
    The sending module MD20 is configured to send, to the eUICCl module, at least one identifier ID of a service S, of a communication profile P, to be implemented by the eUICCl module when said profile P is installed and to the active state in the eUICCl module. The sending module MD20 transmits, for example, the identifier (s) ID to the module eUICCl in a header (or header portion) of the profile P, as explained in more detail later.
    The sending module MD20 is further configured to put on hold the sending of at least part of the communication profile P to the eUICCl module.
    More specifically, in the embodiment considered here, the reception module MD22 is configured to receive, if at least one service is not supported by the OSI operating system, a standby request from the module eUICCl so that the server SV1 (and more particularly the sending module MD20) postpones the sending, or the continuation of sending (in the case where part of the profile has already been sent to the eUICCl module), from the profile P in the eUICCl module.
    Once the OSI operating system has been updated by the eUICCl module, the reception module MD22 of the server SV1 is configured to receive, from the eUICCl module, a request requiring sending or continuing to send ( in case a part of the profile has already been sent to the eUICCl module of profile P.
    The sending module MD20 is further configured, in response to the request mentioned above to send or to continue sending the communication profile P, to send all or part of the profile P to the eUICCl module in order to allow installation. said P profile in the eUICCl module. The reception of the request for sending or of continuation of sending therefore hereby puts an end to the waiting of the sending module MD20.
    In the embodiments described below, the eUICCl module cooperates, via the terminal T, with the server SV1 for providing a profile and with the server SV2 for updating. Various implementations are possible to allow the eUICCl module to interact with the outside via the terminal T in which it is embedded. The terminal T can for example simply play the role of relay between the eUICCl module and the outside (case, for example, of the "Consumer" protocol according to the SGP.22 standard [RSP Technical Specification Version 1.1-09 June 2016]). According to another example, the terminal T can take a larger part in the cooperation between the eUICCl module and the outside (case, for example, of the M2M protocol for "Machine to Machine" according to the SGP.02 standard [Remote Provisioning Architecture for Embedded UICC Technical Specification - Version 3.1-27 May 2016]). Except in special cases, the manner in which the terminal T interfaces between the eUICCl module and the outside will not be described in detail below since this is not necessary for understanding the invention.
    Furthermore, in the embodiments which follow, the operator MNO commands the installation in the eUICCl module of a communication profile PI as illustrated in FIG. 5, according to a particular example. The communication profile PI can comprise a plurality of profile elements (PE), denoted PE1 to PEn, n being an integer greater than or equal to 2. In this example, the first profile element PE1 constitutes the header PEH of the PI profile. In the following embodiments, the profile PEH header constitutes a first portion PR1 of the profile PI and the profile elements PE2 to PEn constitute, in combination, a second portion PR2 of the profile PI.
    As illustrated in FIG. 5, the PEH header of the PI profile comprises a list LT1 of at least one identifier ID of a service associated with said PI profile. Various examples of list LT1 will be described in more detail with reference to FIGS. 7, 9 and 11.
    In a particular example, the PI profile shown in FIG. 5 is, from a structural point of view, in accordance with the aforementioned GSMA standard.
    In a particular example, during the loading and installation phases in the eUICCl module, the PI profile shown in FIG. 5 is in the form of a compact description conforming to the SIMALLIANCE standard.
    A particular embodiment of the invention, implemented by the eUICCl module, the server SV1 for providing a profile and the server SV2 for updating, is now described with reference to FIGS. 5, 6 and 7. For this do, the eUICCl module executes the operating system OS1 to implement a control method according to a particular embodiment, and the profile supply server SV1 executes the operating system OS3 to implement a control method according to a particular embodiment.
    It is assumed here initially that the PI communication profile is not present in the secondary security domain ISD-P1 of the eUICCl module, and that the operator MNO associated with the PI profile attempts to have the PI profile installed in the eUCCl module in order to allow access, on the terminal T, to at least one service S associated with the profile PI.
    As shown in FIG. 5, the profile PEH header comprises a list LT1 of at least one identifier ID of a respective service S associated with the profile PI. As illustrated in FIG. 7, it is assumed here that the list LT1, denoted LTla in this exemplary embodiment, comprises two identifiers ID1, ID2 (collectively denoted ID) corresponding respectively to the services SI, S2 (denoted collectively S). It will be understood that the number and nature of the service or services associated with the PI profile may vary depending on the case.
    As shown in FIG. 6, the profile supply server SV1 sends (A2), to the eUICCl module, the list LTla of the identifiers ID1 and ID2 of the respective services SI and S2, of the communication profile PI, to be implemented when said profile PI is installed and in active state in the eUICCl module.
    The eUICCl module receives (C2) then the list LTla identifying the services SI, S2 of the PI profile to be implemented by the eUICCl module when said PI profile is installed and in the active state in the eUICCl module.
    In the example considered here, during the sending step A2, the server SV1 sends to the module eUICCl a first portion PR1 of the profile PI, this portion comprising the list LTla of the identifiers ID1 and ID2. As illustrated in FIG. 5, it is assumed in this exemplary embodiment that the first portion PR1 constitutes the header PEH of the profile PI, although other implementations are possible. The eUICCl module thus receives in C2 the first portion PR1 (the header PEH in this example) of the profile PI comprising the list LTla.
    Once the first portion PR1 has been sent (A2) to the eUICCl module, the server SV1 is put on hold (A9) until step A14 described later. In a particular example, after sending the ID identifiers A2, the server SV1 is put on hold (A9) on receipt of a request for standby (or suspension) sent by the eUICCl module. As indicated below, this queuing A9 means that the server SV1 (here its sending module MD20) differs from sending to the module eUICCl at least a part of the profile PI, namely the second portion PR2 in the present case.
    Furthermore, following the reception C2 of the first portion PR1, the eUICCl module determines (C4) whether each service S specified in the list LTla received (namely the services SI and S2 in this example) is supported by the system of OS1 operation of the eUICCl module.
    In the case where each service S (namely SI and S2 in this example) is supported by the operating system OS1, the process ends. In this case, the eUICCl module installs (C6) for example the communication profile PI in the secondary security domain ISD-P1, after having received all of the missing portions constituting the profile.
    If, on the other hand, the module eUICCl determines in C4 that at least one service S identified in the list LTla received in C2 is not supported by the operating system OS1, the module eUICCl proceeds to step C8.
    In C8, the eUICCl module sends, to the update server SV2, a request RQ1 to update the OSI operating system. The server SV2 receives the update request RQ1 in B8. In a particular example, the update request RQ1 is sent by the eUICCl module to a predefined network address, this address being for example prerecorded in memory in the eUICCl module.
    In response to the request RQ1, the server SV2 determines whether a UPD update of the OSI operating system is available and, if so, sends (B10) the UPD update to the eUICCl module.
    If such an UPD update of the OSI operating system is available, the eUICCl module receives it in CIO, then proceeds to its installation (C12) so as to allow the OSI operating system to at least partially implement the PI communication profile. In a particular example, installing C12 of the UPD update in the eUICCl module allows its OSI operating system to support at least one service S specified in the LTla list that said OSI operating system did not support ( C4) before said update C12. In a particular example, the installation C12 of the UPD update now allows the OSI operating system to support each service S specified in the list LTla received in C2.
    After completion of the installation C12 of the UPD update, the eUICCl module sends (C14), to the server SV1 for supplying a profile, a request RQ3 to continue (i.e. resume) the reception of the profile from PI communication to be installed in said eUICCl module. As previously indicated, the eUICCl module has already received in C2 the first portion PR1 (namely, the header PEH in this example) of the profile PI, this portion comprising the list LTla. The OSI operating system is now updated, the eUICCl module requests (C14) to the server SV1 the continuation of the reception of the PI profile in order to receive the missing part of the PI profile, namely the second portion PR2 as illustrated in Figure 5 The server SV1 receives at A14 the request RQ3 for continuing to receive the profile PI and, in response to this request RQ3, ends its waiting phase A9 and sends (A16) to the eUICCl module all or part of the profile PI so that the PI profile can be installed in the eUICCl module. In the example considered here, the eUICCl module has already received in C2 a first portion PR1 (the header PEH in this example) of the profile PI. According to this example, the profile supply server SV1 sends in A16 the second portion PR2 (illustrated in FIG. 5) of the profile PI complementary to the first portion PR1 received in C2, so as to allow the eUICCl module to obtain all of the PI profile to install. In a particular example, these first and second portions PR1, PR2 together form the entire profile PI (in this case, the portion PR2 includes the profile elements PE2 to PEn of the profile PI as illustrated in FIG. 5).
    From the profile portions PR1 and PR2 received respectively at C2 and C16, the eUICCl module thus recovers the entire profile PI. The eUICCl module can perform any appropriate processing on the data contained in the PR1 and PR2 portions to obtain the PI profile to be installed.
    During a C18 installation step, the eUICCl module then installs the PI profile. In this example, the PI profile is installed in the secondary security domain ISD-P1 of the eUICCl module.
    Once the PI communication profile is installed (C18), the eUICCl module (and more particularly its privileged security domain IDS-R) is capable of switching the PI profile between an active state and an inactive state. When configured in the active state, the PI profile authorizes the communication terminal T to communicate with the communication network R associated with said PI profile in order, for example, to access the services SI, S2 specified in the PI profile . As already indicated, the PI profile includes for example subscription data making it possible to identify and / or authenticate the user, having subscribed to the services SI, S2, with the operator MNO of the network R.
    It will be understood that other variant embodiments are possible, in which in particular the identifier (s) ID received by the module eUICCl in C2 are not included in a first portion PR1 of the profile PI (the identifiers ID are for example sent in a message independent of the PI profile). In this case, after completion of the installation C12 of the UPD update, the eUICCl module sends in C14, to the server SV1 for providing a profile, an RQ3 request to receive the (and not to continue receiving the) profile from PI communication to be installed in the eUICCl module.
    When an eUICC module detects that its operating system does not support at least one service specified in a profile to be installed, the invention advantageously allows said eUICC module to obtain the necessary update so as to compensate, at least in part, its inability to implement said at least one unsupported service. Once the update has been carried out, the eUICC module can install the profile so as to offer, when the profile in question is in the active state, access to one or more services associated with said profile.
    A particular embodiment of the invention, implemented by the eUICCl module, the server SV1 for providing a profile and the server SV2 for updating represented in FIG. 1, is now described with reference to FIGS. 8 and 9. To do this, the eUICCl module executes the OSI operating system to implement a control method according to a particular embodiment, and the profile supply server SV1 executes the OS3 operating system to implement a method control according to a particular embodiment.
    It is again assumed that the PI communication profile is not present in the secondary security domain ISD-P1 of the eUICCl module, and that the operator MNO associated with the PI profile attempts to have the PI profile installed in the eUCCl module in order to allow access, on the terminal T, to at least one service associated with the PI profile.
    In this example, the PI communication profile to be installed in the eUICCl module is illustrated in Figure 5, as already described above. The header PEH of the profile PI includes in this example a list LT1, this time noted LTlb, as represented in FIG. 9. As for the list LTla previously described, the list LTlb now contained in the header PEH of the PI profile includes the identifiers ID1, ID2 (collectively noted ID) of the services
    SI, S2 (collectively noted S). The list LTlb contained here in the header PEH furthermore comprises, in association with each identifier ID1, ID2 of service, a respective degree of importance DGI, DG2 (collectively noted DG) of the service, this degree of importance DG indicating whether the corresponding S service must be supported by the OS1 operating system when the PI communication profile is installed in the eUICCl module.
    Each degree of importance DG can for example take one of two distinct states, namely: a first state indicating that the associated service S must necessarily be supported by the operating system OS1 when the communication profile PI is installed in the eUICCl module, and a second state indicating that the associated service S does not necessarily have to be supported by the operating system OS1 when the communication profile PI is installed in the eUICCl module.
    As shown in FIG. 8, the profile supply server SV1 sends (A2), to the eUICCl module, the PEH header of the profile PI, in the same way as in the sending step A2 shown in FIG. 6 As indicated above, the list LTlb present in the PEH header of the profile PI includes the identifiers ID1, ID2 of service as well as the degrees of importance DGI, DG2 associated. The number and nature of the services specified in the LTlb list may vary depending on the case.
    It is assumed, in this example, that the services SI, S2 are mandatory services in the sense that the degrees of importance DGI, DG2 associated indicate that these services SI, S2 must necessarily be supported by the operating system OS1 when the PI communication profile is installed in the eUICCl module.
    The eUICCl module receives the PEH header in C2, then determines (C4), as already described with reference to FIG. 6, whether each service S specified in the list LTlb received (namely the services SI and S2 in this example ) is supported by the operating system OS1 of the eUICCl module.
    To do this, the eUICCl module compares here, during the determination step C4, the CAP (s) of the operating system OS1 with each service S specified in the list LT1 received in C2. To this end, the eUICCl module consults its list TB shown in FIG. 2 and compares its capacities CAP1 - CAP4 with the services SI, S2 corresponding respectively to the identifiers ID1, ID2 contained in the list LTlb.
    In the case where the services SI and S2 are supported by the operating system OS1, the process ends. In this case, the eUICCl module installs (C6) for example the PI communication profile in the secondary security domain ISD-P1.
    If, on the other hand, the eUICCl module determines in C4 that at least one of the services SI, S2 identified in the list LTlb is not supported by the operating system OS1, the process continues at step C7.
    It is assumed in this example that the eUICCl module detects in C4 that the service SI is supported by OS1 but that the service S2 is not supported by OS1.
    As shown in FIG. 8, the eUICCl module sends in C7 a request RQ2 for putting on hold (or suspension request) to the server SV1 for supplying a profile in order to defer the continuation of reception of the profile P1. . As already indicated previously, the eUICCl module has already received in C2 a first portion PR1 of the profile Pl to be installed, namely the header PEH containing the list LTlb in this example. The sending of the queuing request RQ2 makes it possible to defer the sending, by the server SV1, of the missing part PR2 of the profile Pl comprising the profile elements PE2 to PEn. In response to this request RQ2, the server SV1 is put on hold (A9), so as to give the time necessary for the eUICCl module to update (if possible) its OSI operating system.
    In C8, the eUICCl module sends an update request RQ1 to update its OSI operating system to the update server SV2, as already described with reference to FIG. 6. The server SV2 receives the update request RQ1 updated in B8. In this example, the request RQ1 comprises a list LT2 comprising the identifier IDN of the service or services S identified in C4 as not being supported by the OSI operating system. Since the S2 service is not supported by OSI in this example, the LT2 list therefore contains the identifier ID2 as the unsupported service IDN identifier.
    In a particular example, the eUICCl module sends in C8, to the update server SV2, the list LT1. In other words, the list LT2 sent in C8 is then identical to the list LT1 received in C2. The LT1 list allows the update server SV2 to determine whether a useful update is available for the eUICCl module.
    As already described with reference to FIG. 6, in response to the request RQ1, the server SV2 determines whether a UPD update of the OSI operating system is available and, if so, sends (B10) the update UPD to the eUICCl module.
    If such an UPD update of the OSI operating system is available, the eUICCl module proceeds to steps CIO and C12 as already described with reference to FIG. 6. More particularly, the eUICCl module receives (CIO) the UPD update then proceeds to its installation (C12) so as to allow the OSI operating system to at least partially implement the communication profile Pl.
    Once the update C12 has been carried out, the eUICCl module determines (C20) whether the OSI operating system supports at least each service S of the communication profile Pl indicated by the degree of importance DG associated as having to be necessarily supported by the OSI operating system. In other words, the eUICCl module checks in C20 whether the OSI operating system, once updated in C12, is able to implement each mandatory service S specified as such in the list LTlb. If so, the process continues in C14. Otherwise, the process ends (the eUICCl module notifies, for example, the server SV1 of providing a profile that it has abandoned the process of installing the profile P1).
    It is assumed here that the services SI and S2 are compulsory and that, thanks to its update UPD, the operating system OSI now supports the services SI, S2. In this case, the eUICCl module performs steps C14, C16 and C18 and the server SV1 performs steps A14, A16, as already described with reference to FIG. 6.
    Thus, the module eUICCl sends in C14, to the server SV1 for providing a profile, a request RQ3 to continue (or resume) the reception of the profile PI to be installed in the module eUICCl. As previously indicated, the eUICCl module has already received in C2 the first portion PR1 (namely, the header PEH in this example) of the profile PI, this portion comprising the list LTlb. The OSI operating system is now updated and capable of implementing the services SI and S2, the eUICCl module requests (C14) the server SV1 to continue receiving the PI profile in order to receive the missing part PR2 of the PI profile. The server SV1 receives at A14 the request RQ3 for continuing to receive the profile PI and, in response to this request RQ3, sends (A16) to the eUICCl module all or part of the profile PI (i.e. the second portion PR2 in this example) so that the PI profile can be installed in the eUICCl module.
    From the profile portions PR1 and PR2 received respectively in C2 and C16, the eUICCl module thus retrieves the entire profile PI and installs it in the secondary security domain ISD-P1 during an installation step C18 , as already described with reference to FIG. 6.
    Once the PI communication profile is installed (C18), the eUICCl module (and more particularly its privileged security domain IDS-R) is capable of switching the PI profile between an active state and an inactive state, as also described with reference to Figure 6.
    It will also be understood here that other alternative embodiments are possible, in which in particular the eUICCl module does not receive in C2 the service identifier or identifiers S in a first portion PR1 of the profile PI but in any other appropriate form (in a any message independent of the PI profile for example). In this case, the eUICCl module sends in C14, to the profile supply server SV1, a request RQ3 to receive the (and not to continue receiving) the communication profile PI to be installed in the eUICCl module.
    The invention makes it possible to update, if necessary, the operating system of an eUICC module prior to the installation of a communication profile in order to ensure that the profile can be used in the best conditions by the user. eUICC module. The invention makes it possible in particular to ensure that the eUICC module is capable of implementing each mandatory service specified in the profile considered before proceeding with the installation of the profile in the eUICC module in question.
    The invention also makes it possible to offer sufficient time to the eUICC module to update its operating system, when such an update is necessary, before receiving the missing part or parts of the profile to install. Advantageously, the eUICC module can possibly abandon the download of the profile in question if it detects that no update allows it to support each mandatory service associated with said profile, thus saving network resources of the eUICCl module. and the profile supply server SV1.
    A particular embodiment of the invention, implemented by the eUICCl module, the server SV1 for providing a profile and the server SV2 for updating, is now described with reference to FIGS. 10 and 11. To do this, the eUICCl module executes the OSI operating system to implement a control method according to a particular embodiment, and the profile supply server SV1 executes the OS3 operating system to implement a control method according to a particular embodiment.
    It is again assumed that the communication profile Pl is not present in the secondary security domain ISD-P1 of the module eUICCl, and that the operator MNO associated with the profile Pl attempts to have the profile Pl installed in the module eUCCl in order to allow access, on the terminal T, to at least one service associated with the profile Pl.
    In this example, the communication profile Pl to be installed in the eUICCl module is illustrated in FIG. 5, as already described previously. The PEH header of the profile Pl includes in this example a list LT1, this time noted LTlc, as shown in FIG. 11. It is now assumed that the list LTlc contained in the PEH header of the profile Pl includes the identifiers ID1 to ID4 (collectively noted ID) of the respective services SI to S4 (collectively noted S). The list LTlc further comprises, in association with each identifier ID1 to ID4, a respective degree of importance DGI to DG4 (collectively denoted DG) as already described with reference to FIG. 9, this degree of importance DG indicating whether the service The corresponding S must be supported by the OSI operating system when the communication profile P1 is installed in the eUICCl module.
    It is assumed in this example that the services SI, S2 are indicated as mandatory services by their degree of importance DGI, associated DG2, and that the services S3, S4 are indicated as optional services by their respective degree of importance DG3, DG4.
    In this exemplary embodiment illustrated in FIG. 10, the server SV1 performs the steps A2 to A9 and the eUICCl module performs the steps C2 to C12 and C20, as previously described with reference to FIG. 8. It is assumed for example here that the services mandatory SI, S2 are not initially supported (in C4) by the OSI operating system thus causing an update C12 of the OSI operating system as already described with reference to FIG. 8.
    During the determination step C20, the eUICCl module determines whether its OSI operating system, now updated, supports at least each mandatory service S of the profile Pl, that is to say each service (SI and S2 in this example) indicated by the degree of importance DG associated as having to be necessarily supported by the OSI operating system. If so, the process continues in C30. Otherwise, the process ends (the eUICCl module notifies, for example, the server SV1 of providing a profile that it has abandoned the process of installing the profile P1).
    During a determination step C30, the eUICCl module determines whether its OSI operating system, now updated, also supports each optional service S of the profile PI, that is to say each service (S3 and S4 in this example) indicated by the degree of importance DG associated as not having to be necessarily supported by the OSI operating system. If so, the process resumes in C14 as already described with reference to FIG. 8. Otherwise, the process continues in C32.
    It will be noted that steps C20 and C30 can be carried out one after the other, or simultaneously by the eUICCl module.
    It is assumed in this example that the eUICCl module determines in C30 that the optional service S3 is supported by the OSI operating system but that the optional service S4 is not supported by the OSI operating system.
    At this stage, various implementations of the invention are possible. In the example considered here, the eUICCl module determines in C32 if a PR parameter was received in the PEH header during the reception step C2, this parameter indicating whether the eUICCl module is authorized to (or must) implement the S service (s) of the PI profile in a restricted manner. Here, by restricted use (or implementation) is meant the fact that, when the profile is in the active state, the eUICCl module only partially implements said profile in the sense that at least one optional service of said profile n is not supported by the eUICC module. In the case of a restricted use of a profile (or more precisely of the profile services), the eUICCl module operates in MD2 mode called "restricted use".
    In the embodiment considered here, the server SV1 for example sends to A2 the first portion PR1 (here the header PEH) which includes the parameter PR. To do this, an SM-DP server (as shown in Figure 1) for example inserts this PR parameter beforehand into the first portion PR1 of the PI profile during a preparation or personalization phase (creation of the profile ...) . The PR parameter is for example inserted by the SM-DP server in execution rules (or "policy rules" in English) present in the PI profile. These rules, for example, comply with the standard. The SM-DP server then transmits all or part of the PI profile to the SV1 server, for sending (A2) to the eUICCl module of the first portion PR1 with the parameter PR.
    Depending on how it is configured, the SV1 server (cooperating with the SM-DP server as indicated above) can indicate using this PR parameter that the eUICCl module is authorized to, or must, configure in mode restricted use when at least one optional service is not supported.
    If the module eUICCl determines in C32 that the parameter PR has indeed been received in the header PEH during the reception step C2, the process continues in C34. Otherwise, the eUICCl module sends an MSG1 message asking the server SV1 whether it is authorized to (or must) operate in MD2 restricted use mode. In a particular example, the message MSG1 further comprises a list LT3 comprising the identifier IDN2 of the optional service or services S of the profile PI which the OSI operating system does not support. According to a particular example, the message MSG1 includes an identifier of the PI profile to be installed and implemented in the eUICCl module.
    In response to the message MSG1 received at A32, the profile supply server SV1 determines (A34) whether the eUICCl module is authorized (or must) implement the profile PI according to the MD2 mode of restricted use. This determination A34 can, if necessary, be carried out as a function of the list LT3 and / or of the identifier of the profile PI if these elements are present in the message MSG1. The operator of the SV1 server can thus remotely indicate to each eUICC module whether the MD2 mode of restricted use can (or must) be applied.
    If it determines in A34 that the restricted use mode MD2 is authorized (or required), the server SV1 sends (A36) in response a second message MSG2 indicating that the eUICCl module is authorized to (or must) implement in a restricted manner (MD2 mode) the S services of the PI profile.
    The eUICCl module receives the message MSG2 in C36 and determines (C38), from the message MSG2 of the server SV1, whether it should implement the profile PI in MD2 mode of restricted use. If not, the process ends. Otherwise (MD2 mode authorized / required), the process continues at step C18 during which the eUICCl module installs the PI profile as previously described. To do this, the eUICCl module performs, for example, steps C14 and C16 (not shown in FIG. 10) as already described with reference to FIGS. 6 and 8 in order to receive the missing part PR2 of the profile PI. Alternatively, the eUICCl module receives the PR2 part of the PI profile in response to the MSG1 message, without the sending of a specific request by the eUICCl module.
    If, moreover, the eUICCl module determines in C32 that the parameter PR has indeed been received in the header PEH during the reception step C2, the process continues in C34. During the determination step C34, the eUICCl module determines, from the parameter PR previously received, whether it should implement the profile PI in MD2 mode of restricted use. If not, the process ends. Otherwise (MD2 mode authorized / required), the process continues at step C18 as already above.
    In a particular example, the eUICCl module determines in C34 that it must implement the PI profile in MD2 mode of restricted use only if the PR parameter received in C2 is in a predefined state. The PR parameter can for example be defined by a bit coded in the PEH header received in C2, this bit triggering or not the passage of the eUICCl module in MD2 mode of restricted use according to the value which has been assigned to it.
    Once the installation step C18 has been carried out, the eUICCl module is configured, when this PI profile is in the active state, to partially implement (in MD2 mode of restricted use) the S services of the PI profile (in this example, only the services SI, S2 and S3 are implemented).
    The eUICCl module optionally sends to the server SV1 a notification indicating that said eUICCl module is configured to implement the services S of the PI profile in a restricted manner (MD2 mode).
    The invention thus allows an eUICC module to partially implement a communication profile when at least one optional service of the profile is not supported by the operating system of the eUICC module, insofar as such implementation partial work is authorized or required by the associated MNO operator.
    In a particular embodiment, following the installation C18 of the profile Pl, the eUICCl module performs (C40) a marking of the communication profile Pl so as to indicate that at least one optional service S of the profile Pl (namely the service S4 in this example) is not supported by the OS1 operating system. This marking makes it possible to indicate to a third party that the eUICCl module, and therefore the terminal T, implements the profile Pl in MD2 mode of restricted use. The terminal T is for example configured, on the basis of this marking, to supply a notification to a user to indicate to him that the profile P1 is used in a restricted manner (mode MD2).
    In a particular example, during the marking step C40, the eUICCl module modifies (or assigns a value to), in the communication profile Pl installed in said eUICCl module, a parameter to indicate that it is configured to set operates in a restricted manner the services S of the profile Pl. In a particular example, this modification is carried out in a register, associated with the profile Pl. This register is for example contained in the secondary security domain ISD-P1, or in the domain of privileged security ISD-R of the eUICCl module, or more generally in a memory of the eUICCl module.
    In a variant of the example described above with reference to FIG. 10, in response to the request RQ1 for updating the operating system OS1, the eUICCl module receives a notification from the update server SV2 indicating the or services not supported by the OS1 operating system which would become supported if the available UPD update is installed in the eUICCl module. The eUICCl module can thus determine, from this notification, whether operation in MD2 mode of restricted use is required before even performing the operating system update. In a particular example, if operation in MD2 mode is required, the eUICCl module determines, before updating the operating system OS1, whether the server SV1 authorizes (or requests) operation in MD2 mode of restricted use , as for example previously described with reference to steps C32-C38. In this way, it is in particular possible to avoid an update of the operating system of the eUICC module if such an update does not allow the eUICC module to subsequently implement the communication profile to be installed, this which saves resources in the network.
    Note also that in the event that the eUICCl module implements the P1 profile according to the MD2 mode of restricted use, a subsequent update of the operating system OS1 can be carried out by the eUICCl module in order to reduce the number of optional services not supported or, if applicable, so that each optional service of the P1 profile is supported by the eUICCl module. In the latter case, the eUICCl module can operate in MD1 mode of unrestricted use (normal) so that each mandatory and optional service of the profile P1 is implemented when the latter is in the active state in the eUICCl module.
    We now consider a particular embodiment according to which the method described with reference to FIG. 10 continues in FIG. 12. It is assumed here that the eUICCl module implements in a restricted manner the profile P1 since its operating system OS1 does not not support the optional S4 service of profile Pl.
    More particularly, after a determined time interval, the eUICCl module sends (C50) a new request RQ4 for updating its operating system OS1. In response to this request RQ4 received in B50, the server SV2 sends (B52) an update UPD2 of the operating system OS1 that the eUICCl module receives in C52. Steps C50-C52 and B50B52 are for example carried out in an identical manner respectively to steps C8-C10 and B8B10 previously described with reference to FIGS. 6, 8 and 10.
    If an UPD2 update is actually received in C52, the eUICCl module installs (C54) this update in the same way as the C12 update step described above, then determines (C56) if each optional service S of the profile P1 is now supported by the operating system OS1 (in the same way as in step C30 previously described). If this is the case, the process continues in C58. Otherwise, the process ends.
    In C58, the eUICCl module is configured in MD1 mode of unrestricted use of the Pl profile and, optionally, modifies the marking (or removes the marking) of the Pl profile previously made in C40 (Figure 10) so as to indicate that each optional service S of profile Pl (namely services S3, S4 in this example) is supported by the operating system OS1.
    The eUICCl module sends (C60) an MSG3 notification to the profile supply server SV1 to indicate that it is now operating in MD1 mode of unrestricted use vis-à-vis the Pl profile. Following this MSG3 notification received in A60 , the server SV1 sends (A62) possibly an acknowledgment message MSG4, received by the eUICCl module in C62.
    A person skilled in the art will understand that the embodiments and variants described above only constitute nonlimiting examples of implementation of the invention. In particular, a person skilled in the art can envisage any adaptation or combination of the embodiments and variants described above in order to meet a very specific need.
    权利要求:
    Claims (18)
    [1" id="c-fr-0001]
    1. Control method implemented by an on-board subscriber identity module (eUICCl) capable of cooperating with a communication terminal (T), said control method comprising:
    - reception (C2) of at least one identifier (ID) of a respective service, of a communication profile (P), to be implemented when said communication profile is installed and in the active state in the module on-board subscriber identity;
    - determination (C4) of whether each service (S) is supported by an operating system (OS1) of the on-board subscriber identity module;
    - if not, sending (C8) a request to update the operating system;
    - if an update (UPD) of the operating system is received (CIO) in response to said sending (C8), installation (C12) of said update allowing the operating system to at least partially implement said communication profile (P); and
    - after completion of said installation, sending (C14) of a request to receive or continue receiving the communication profile (P), including said at least one service (S), to be installed in said on-board subscriber identity module .
    [2" id="c-fr-0002]
    2. Method according to claim 1, comprising, in response to said request to receive or continue said reception, a reception (C16) of all or part of the communication profile so as to allow the installation of the profile in the identity module. onboard subscriber.
    [3" id="c-fr-0003]
    3. Method according to claim 1 or 2, comprising the installation (C18) of the communication profile (P) in the subscriber identity module onboard once said profile obtained in its entirety.
    [4" id="c-fr-0004]
    4. Method according to any one of claims 1 to 3, said communication profile authorizing, when installed and in the active state in the on-board subscriber identity module, the communication terminal to communicate with a network communication (R) associated with said communication profile.
    [5" id="c-fr-0005]
    5. Method according to any one of claims 1 to 4, in which the method comprises a comparison of the capacities of the operating system with each service (S) associated with said at least one identifier (ID);
    the determination of whether at least one said service (S) is not supported by the operating system being carried out on the basis of the result of said comparison.
    [6" id="c-fr-0006]
    6. Method according to any one of claims 1 to 5, in which the reception of said at least one identifier comprises the reception of a first portion of the communication profile, said first portion comprising said at least one identifier.
    [7" id="c-fr-0007]
    7. The method of claim 6, the first portion being a header portion of the communication profile.
    [8" id="c-fr-0008]
    8. The method of claim 6 or 7, the method comprising, after completion of said installation of the update, sending said request to continue receiving the communication profile (Pl) to receive at least a second portion (PR2) of the communication profile supplementing said first portion (PR1) so as to obtain the entire communication profile (Pl) to be installed in the on-board subscriber identity module.
    [9" id="c-fr-0009]
    9. Method according to any one of claims 1 to 8, wherein said at least one identifier (ID) is received from a profile supply server (SV1), the method comprising, if at least one said service (S) is not supported by the operating system (OS1), the sending (C7) of a request (RQ2) for queuing to the profile supply server in order to delay the reception of at least a part (PR2) of the communication profile.
    [10" id="c-fr-0010]
    10. Method according to any one of claims 1 to 9, in which, on receipt of said at least one identifier, the method comprises:
    - reception (C2), in association with each service identifier (ID), of a degree of importance (DG) of said service, said degree of importance indicating whether the corresponding service must be supported by the operating system (OS1) when the communication profile is installed in the on-board subscriber identity module.
    [11" id="c-fr-0011]
    11. The method of claim 10, wherein the embedded subscriber identity module sends (C14) said request (RQ3) to receive or continue receiving the communication profile (Pl) only if the system d operation (OS1), once updated, supports at least each service (SI, S2) of the communication profile indicated by the degree of importance (DGI, DG2) associated as having to be necessarily supported by the operating system .
    [12" id="c-fr-0012]
    12. The method of claim 10 or 11, wherein if the operating system (OS1), once updated, does not support at least one service (S4) of the communication profile indicated by the degree of importance associated (DG4) as not necessarily having to be supported by the operating system, the embedded subscriber identity module:
    - proceeds to send (C14) of said request to receive or continue receiving the communication profile (PI); and
    - realizes (C40) a marking of the communication profile (PI), once said profile installed in the on-board subscriber identity module, so as to indicate that at least one service (S4) of the communication profile, not in front not necessarily be supported by said operating system, is not supported by said operating system.
    [13" id="c-fr-0013]
    13. The method of claim 12, wherein the marking (C40) comprises a modification, in the communication profile (PI) installed in the on-board subscriber identity module, of a parameter to indicate that the identity module onboard subscriber is configured to implement said at least one service of the communication profile in a restricted manner.
    [14" id="c-fr-0014]
    14. Method according to any one of claims 10 to 13, in which if the operating system (OSI), once updated, does not support at least one service (S4) of the indicated communication profile (PI) by the associated degree of importance (DG4) as not necessarily having to be supported by the operating system, the method comprises:
    - sending of a notification indicating that the on-board subscriber identity module is configured to implement said at least one service of the communication profile in a restricted manner.
    [15" id="c-fr-0015]
    15. Method according to any one of claims 10 to 14, in which, during said reception (C2), said at least one identifier (ID) and each associated degree of importance (DG) is received in a header (PR1 ) of said communication profile (PI), said header further comprising a parameter (PR), in which, after completion of said installation (C12) of the update, the on-board subscriber identity module (eUICCl) sends ( C14) said request to continue receiving the communication profile (P) only if the parameter (PR) is in a predefined state.
    [16" id="c-fr-0016]
    16. Control method implemented by a profile supply server (SV1) to supply a communication profile to an on-board subscriber identity module (eUICCl) cooperating with a communication terminal (T), comprising:
    - sending (A2), to said on-board subscriber identity module, of at least one identifier (ID) of a respective service (S), of a communication profile (P), to be implemented when said profile communication is installed and in the active state in the on-board subscriber identity module;
    - putting on hold (A9) the sending of at least part of the communication profile to the on-board subscriber identity module;
    - after updating said operating system by the on-board subscriber identity module, receipt (A14) of a request to send or continue sending the communication profile (P), including said at least one services) ; and
    - in response to said request to send or continue sending the communication profile, sending (A16) of all or part of the communication profile in order to allow the installation of said profile in the on-board subscriber identity module.
    [17" id="c-fr-0017]
    17. Computer program (OSI; OS3) comprising instructions for the execution of the steps of a control method according to any one of claims 1 to 16 when said program is executed by a computer.
    [18" id="c-fr-0018]
    18. Embedded subscriber identity module capable of cooperating with a communication terminal (T), said embedded subscriber identity module comprising:
    - a reception module (MD2) configured to receive at least one identifier (ID) from a respective service, from a communication profile (P), to be implemented when said communication profile is installed and in the state active in the on-board subscriber identity module;
    - a determination module (MD4) configured to determine whether each service is supported by an operating system (OSI) of the embedded subscriber identity module;
    - an update module (MD6) configured, if each service is not supported by said operating system, to send a request for updating the operating system, said update module (MD6) being configured, if an update (UPD) of the operating system is received in response to said update request, to install said update allowing the operating system to at least partially implement said profile communication (P); and
    a sending module (MD8) configured, after completion of said update installation, to send a request to receive or continue reception of the communication profile (P), including said at least one service (S), to install in said embedded subscriber identity module.
    1/6
    R
    2/6
    CAP
    CAP1
    CAP2
    CAP3
    CAP4
    TB
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3542563B1|2020-11-11|Installation of a profile in an embedded subscriber identity module
    EP3117640B1|2018-08-29|Embedded subscriber identity module capable of managing communication profiles
    EP3029968B1|2019-07-31|Method for provisioning a subscriber profile inside a secure module
    EP1483930B1|2011-09-28|Method of updating an authentication algorithm in a computer system
    EP0897250A1|1999-02-17|Improved process for charging a predetermined list of articles through a mobile terminal controlled by a subscriber interface module, order, and apparatus therefor
    EP3219157B1|2018-10-31|Euicc card storing short numbers per subscriber profile to notify a subscription management server
    EP3395089B1|2019-11-27|Embedded subscriber identity module comprising communication profiles
    EP3395090B1|2020-05-13|Method for controlling an embedded subscriber identity module
    EP1959699B1|2009-04-29|Continuity of service by using a backup HLR
    FR3013479A1|2015-05-22|NOTIFICATION METHOD FOR CONFIGURING A SECURE ELEMENT
    EP2595417A1|2013-05-22|Method for selecting an application in a terminal and terminal implementing said method
    EP3648490A1|2020-05-06|Management of subscriber profiles simultaneously active in an euicc card using a plurality of separate links
    EP3195638B1|2018-07-04|Method for administering life cycles of communication profiles
    FR3077457A1|2019-08-02|METHOD FOR MANAGING ACCESS TO A TELECOMMUNICATION INFRASTRUCTURE COMPRISING PUBLIC AND PRIVATE NETWORKS AND ASSOCIATED DEVICES
    EP3531729A1|2019-08-28|Configuration of an on-board subscriber identity module
    FR3002408A1|2014-08-22|Method for configuring supply profile of terminal e.g. mobile phone, by embedded universal integrated circuit card, involves obtaining and storing identifier of current supply profile compatible with current use region of terminal
    EP3637871A1|2020-04-15|Subscriber identification card for a mobile terminal
    EP3479551B1|2021-08-04|Method for synchronizing context dataof network functions in a mobile network
    EP3917184A1|2021-12-01|Method and devices for management of communication profiles
    EP3278542B1|2019-01-02|System and method for executing an application on a terminal provided with a chip card
    FR2939590A1|2010-06-11|Network interface card i.e. Ethernet interface card, personalization method for communication gateway, involves transmitting personalization data from personalization device to network interface card in case of positive detection of access
    FR3057431A1|2018-04-13|TECHNIQUE FOR TRANSFERRING A PROFILE OF ACCESS TO A NETWORK
    FR2884384A1|2006-10-13|METHOD FOR CONTROLLING THE PRESENCE OF A TERMINAL ON A POINT OF ACCESS TO A TELEPHONY NETWORK
    FR3010273A1|2015-03-06|METHOD OF PROCESSING AUTHENTICATION KEYS IN A WIRELESS TELECOMMUNICATIONS SYSTEM AND ASSOCIATED TELECOMMUNICATION SYSTEM
    WO2013102722A1|2013-07-11|Method of activation on a second network of a terminal comprising a memory module associated with a first network
    同族专利:
    公开号 | 公开日
    ES2840176T3|2021-07-06|
    EP3542563A1|2019-09-25|
    CN110169099A|2019-08-23|
    US10820189B2|2020-10-27|
    US20190364416A1|2019-11-28|
    FR3059194B1|2019-06-28|
    KR20190084110A|2019-07-15|
    EP3542563B1|2020-11-11|
    WO2018091853A1|2018-05-24|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP2963955A1|2014-07-01|2016-01-06|Samsung Electronics Co., Ltd.|Method and apparatus for installing profile for euicc|
    EP3029968A1|2014-12-04|2016-06-08|Oberthur Technologies|Method for provisioning a subscriber profile inside a secure module|EP3917184A1|2020-05-28|2021-12-01|IDEMIA France|Method and devices for management of communication profiles|EP2056630B1|2007-11-01|2010-12-22|Research In Motion Limited|Method and apparatus for updating a terminal profile|
    US20140162640A1|2010-06-28|2014-06-12|Xipeng Zhu|System and method for subscription data optimization|
    US8555067B2|2010-10-28|2013-10-08|Apple Inc.|Methods and apparatus for delivering electronic identification components over a wireless network|
    US10111092B2|2012-11-06|2018-10-23|Kt Corporation|Terminal device having subscriber identity device and method for selecting profile thereof|
    EP2802162A1|2013-05-07|2014-11-12|Gemalto SA|Method for accessing a service, corresponding device and system|
    EP3297309B1|2015-04-13|2019-06-19|Samsung Electronics Co., Ltd.|Technique for managing profile in communication system|
    US10187788B2|2015-12-11|2019-01-22|Apple Inc.|Embedded universal integrated circuit card file system management with profile switching|
    US9831903B1|2016-07-28|2017-11-28|Apple Inc.|Update of a trusted name list|US10785645B2|2015-02-23|2020-09-22|Apple Inc.|Techniques for dynamically supporting different authentication algorithms|
    FR3074002B1|2017-11-21|2019-11-08|Sigfox|METHOD FOR ASSISTING THE REMOTE CONFIGURATION OF A EUICC CARD AND SYSTEM IMPLEMENTING SAID METHOD|
    US11146948B1|2019-11-05|2021-10-12|Sprint Communications Company L.P.|Electronic subscriber identity moduletransfer via activation code|
    US11146944B1|2020-02-20|2021-10-12|Sprint Communications Company L.P.|Mobile phone peer-to-peer electronic subscriber identity moduletransfer|
    法律状态:
    2017-10-19| PLFP| Fee payment|Year of fee payment: 2 |
    2018-05-25| PLSC| Search report ready|Effective date: 20180525 |
    2018-10-24| PLFP| Fee payment|Year of fee payment: 3 |
    2019-10-22| PLFP| Fee payment|Year of fee payment: 4 |
    2020-10-21| PLFP| Fee payment|Year of fee payment: 5 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1661289|2016-11-21|
    FR1661289A|FR3059194B1|2016-11-21|2016-11-21|INSTALLATION OF A PROFILE IN AN INBOX SUBSCRIBER IDENTITY MODULE|FR1661289A| FR3059194B1|2016-11-21|2016-11-21|INSTALLATION OF A PROFILE IN AN INBOX SUBSCRIBER IDENTITY MODULE|
    ES17812007T| ES2840176T3|2016-11-21|2017-11-20|Installing a profile on an integrated subscriber identity module|
    EP17812007.7A| EP3542563B1|2016-11-21|2017-11-20|Installation of a profile in an embedded subscriber identity module|
    PCT/FR2017/053173| WO2018091853A1|2016-11-21|2017-11-20|Installation of a profile in an embedded subscriber identity module|
    KR1020197017511A| KR20190084110A|2016-11-21|2017-11-20|Installation of profiles in the embedded subscriber identity module|
    CN201780082476.6A| CN110169099A|2016-11-21|2017-11-20|Installation of the profile in embedded subscriber mark module|
    US16/462,424| US10820189B2|2016-11-21|2017-11-20|Installation of a profile in an embedded subscriber identity module|
    [返回顶部]